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Abstract 


This memo documents a process intended to organize the future 
development of the Session Initiation Protocol (SIP) and related work 
in the Real-time Applications and Infrastructure (RAI) Area. As the 
environments in which SIP is deployed grow more numerous and diverse, 
modifying or extending SIP in certain ways may threaten the 
interoperability and security of the protocol; however, the IETF 
process must also cater to the realities of existing deployments and 
serve the needs of the implementers working with SIP. This document 
therefore defines the functions of two long-lived working groups in 
the RAI Area that are, respectively, responsible for the maintenance 
of the core SIP specifications and the development of new efforts to 
extend and apply work in this space. This document obsoletes RFC 
3427. 


Status of This Memo 
This memo documents an Internet Best Current Practice. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


BCPs is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc5727. 
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Copyright Notice 


Copyright (c) 2010 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 


This document may contain material from IETF Documents or IETF 
Contributions published or made publicly available before November 
10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
modifications of such material outside the IETF Standards Process. 
Without obtaining an adequate license from the person(s) controlling 
the copyright in such materials, this document may not be modified 
outside the IETF Standards Process, and derivative works of it may 
not be created outside the IETF Standards Process, except to format 
it for publication as an RFC or to translate it into languages other 
than English. 
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dn. 


History and Development 


The Session Initiation Protocol (SIP) [RFC3261] has grown well beyond 
its origins in Internet-based multimedia sessions and now enjoys 
widespread popularity in Voice-over-IP or IP telephony applications, 


both inside IETF and within other standards groups. One result of 
this popularity has been a continual flood of proposals for SIP 
modifications and extensions. The challenge for IETF management of 


SIP has been to preserve baseline interoperability across its many 
implementations 


In order to defend SIP against changes that might reduce 
interoperability, the working group chairs and Area Directors 
responsible for its management authored the SIP change process 
[RFC3427]. That document defined the role of the SIP and SIPPING 
Working Groups (WGs) in shepherding ongoing work on the SIP standard. 
It also defined ways that external working groups or bodies can 
define extensions intended for limited usage, especially through the 
"P-" header field mechanism. 


Over time, however, the management structure of RFC 3427 has 
demonstrated some limitations. The first and most significant of 
these concerns "P-" header fields. While "P-" header fields require 
expert review and IESG shepherding, in practice IETF oversight of 
these header fields is quite limited, and the value added by the IETF 
supervising their development remains unclear. More importantly, the 
presence of a "P-" in front of a header field name does nothing to 
prevent a popular header field from seeing deployment outside of the 
original "limited usage" it envisioned; a prominent example of this 
today is the P-Asserted-Identity (PAID) header field, described in 
RFC3325 [RFC3325]. 


Consequently, this document obsoletes RFC 3427 and describes a new 
structure for the management of deliverables in the Real-time 


Applications and Infrastructure Area. 


1. The IETF SIPCORE Working Group 


Historically, the IETF SIP Working Group (sip) was chartered to be 
the "owner" of the SIP protocol [RFC3261] for the duration of the 
working group. All changes or extensions to SIP were first required 
to exist as SIP Working Group documents. The SIP Working Group was 
charged with being the guardian of the SIP protocol for the Internet, 
and therefore was mandated only to extend or change the SIP protocol 
when there were compelling reasons to do so. 
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The SIPCORE Working Group replaces the function of the SIP Working 
Group in the original [RFC3427] account. Documents that must be 
handled by the SIPCORE Working Group include all documents that 
update or obsolete RFCs 3261 through 3265 or their successors. All 
SIP extensions considered in SIPCORE must be Standards Track. They 
may be based upon requirements developed externally in other IETF 
working groups. 


Typical IETF working groups do not live forever; however, SIPCORE’s 
charter is open-ended in order to allow it to remain the place where 
core SIP development will continue. In the event that the SIPCORE 
Working Group has closed and no suitable replacement or follow-on 
working group is active (and this specification also has not been 
superseded), then when modifications to the core SIP protocol are 
proposed, the RAI Area Directors will use the non-working-group 
Standards Track document process (described in Section 6.1.2 of RFC 
2026 [RFC2026]) using the SIPCORE mailing list and Designated Experts 
from the SIP community for review. 


It is appropriate for any IETF working group to develop SIP event 
packages [RFC3265], but the working group must have charter approval 
to do so. The IETF will also require [RFC5226] IETF Review for the 
registration of event packages developed outside the scope of an IETF 
working group. Instructions for event package registrations are 
provided in Section 4.1. 


1.2. The IETF DISPATCH Working Group 


Historically, the IETF Session Initiation Protocol Proposal 
Investigation (sipping) Working Group was chartered to be a filter in 
front of the SIP Working Group. This working group investigated 
requirements for applications of SIP, some of which led to requests 
for extensions to SIP. These requirements may come from the 
community at large or from individuals who are reporting the 
requirements as determined by another standards body. 


The DISPATCH Working Group replaces the function of the SIPPING WG, 
although with several important changes to its functionality -- the 
most notable being that its scope expands beyond just SIP to the 
entire work of the RAI Area. Like SIPPING, DISPATCH considers new 
proposals for work in the RAI Area, but rather than taking on 
specification deliverables as charter items itself, DISPATCH 
identifies the proper venue for work. If no such venue yet exists in 
the RAI Area, DISPATCH will develop charters and consensus for a BoF, 
working group, or exploratory group [RFC5111] as appropriate. Unlike 
the previous change structure, a DISPATCH review of any proposed 
change to core SIP is not required before it progresses to SIPCORE; 
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however, any new proposed work that does not clearly fall within the 
charter of an existing RAI Area effort should be examined by 
DISPATCH. 


In reaction to a proposal, the DISPATCH Working Group may determine 
that: 


1. these requirements justify a change to the core SIP 
specifications (RFCs 3261 through 3265) and thus any resulting 
work must transpire in SIPCORE; 


2. these requirements do not change the SIP core specifications but 
require a new effort in the RAI Area (be that a working group, a 
BoF, or what have you); 


3. these requirements fall within the scope of existing chartered 
work in the RAI Area; or 


4. the proposal should not be acted upon at this time. 


Because the SIP protocol gets so much attention, some application 
designers may want to use it just because it is there, such as for 
controlling household appliances. DISPATCH should act as a filter, 
accepting only proposals that play to the strengths of SIP, not those 
that confuse its applicability or ultimately reduce its usefulness as 
a means for immediate personal communications on the Internet. 


In practice, it is expected that the DISPATCH WG behaves as a RAI 
"Open Area" working group, similar to those employed in other areas 
of the IETF. While it does not have the traditional deliverables of 
a working group, DISPATCH may, at the discretion of its chairs and 
Area Directors, adopt milestones in accordance with standard working 
group milestone-adoption procedures, such as the production of 
charter text for a BoF or working group, a "—-00" problem statement 
document that explicates a proposed work effort, or a document 
explaining why a particular direction for standards development was 
not pursued. 


2. Terminology 
In this document, the key words "MAY", "MUST", "MUST NOT", "SHOULD", 
and "SHOULD NOT", are to be interpreted as described in [RFC2119]. 


This document additionally uses [RFC5226] language to describe IANA 
registrations. 
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3. Introducing New Work to RAI 


As with any new work in the IETF, proposals are best formulated in 
individual Internet-Drafts. New ideas arising within the chartered 
scope of a RAI Area working group naturally should be treated as 
candidates for adoption as a working group item there. Experience 
has demonstrated that authoring a problem statement or set of initial 
requirements prior to (or at least separately from) submitting a 
protocol mechanism speeds the consensus-making process significantly. 
A problem statement should explain what problem needs to be solved, 
why existing mechanisms are insufficient, and, for proposals to 
modify SIP, why SIP is the appropriate solution for this problem. A 
problem statement must also detail any security issues that may 
result from meeting these requirements. When proposed new work does 
not fall within the bounds of existing RAI Area working group 
charters, the DISPATCH Working Group assists the authors of 
proposals, the RAI Area Directors and the RAI community to decide the 
best way to approach the problem. Authors of proposals may submit 
their problem statements to the DISPATCH Working Group for community 
consideration and review. 


The DISPATCH Working Group chairs, in conjunction with the RAI Area 
Directors, will determine if the particular problems raised in the 
requirements problem statement are indeed outside the charter of 
existing efforts and, if so, if they warrant a DISPATCH milestone for 
the definition of a new effort; this DISPATCH deliverable may take 
the form of a problem statement Internet-Draft, charter, or similar 
milestone that provides enough information to make a decision, but 
must not include protocol development. The DISPATCH Working Group 
should consider whether the requirements can be merged with other 
requirements from other applications, and refine the problem 
statement accordingly. 


Once a new effort has been defined in DISPATCH and there is working 
group consensus that it should go forward, if the new effort will 
take the form of a working group or BoF, then the ADs will present 
the proposed new effort charter to the IESG and IAB, in accordance 
with the usual chartering process. If the new effort involves the 
rechartering of an existing working group, then similarly the 
existing working group rechartering functions will be performed by 
the appropriate WG chairs and ADs. If the IESG (with IAB advice) 
approves of the new charter or BoF, the DISPATCH Working Group has 
completed its deliverable and the new effort becomes autonomous. 


Anyone proposing requirements for new work is welcome to jointly 
develop, in a separate Internet-Draft, a mechanism that would meet 
the requirements. No working group is required to adopt the proposed 
solution from this additional Internet-Draft. 
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Work overseen by the SIPCORE Working Group is required to protect the 
architectural integrity of SIP and must not add features that do not 
have general use beyond the specific case. Also, SIPCORE must not 
add features just to make a particular function more efficient at the 
expense of simplicity or robustness. 


The DISPATCH process is not the sole place that requirements for new 
work are considered in the RAI Area. For example, some working 
groups generate requirements for SIP solutions and/or extensions. 

At the time this document was written, groups with such chartered 
deliverables include SIP for Instant Messaging and Presence 
Leveraging Extensions (simple), Basic Level of Interoperability for 
SIP Services (bliss) and Session Peering for Multimedia Interconnect 
(speermint). The work of these and similar groups is not affected by 
the DISPATCH process. 


Of course, the RAI Area Directors may accept charter revisions from 
existing working groups that add new milestones or scope to their 
charters at their discretion, in the standard IETF manner, without 
any actions on the part of the DISPATCH Working Group. DISPATCH 
exists to assist new work in finding a home expeditiously in those 
cases where it does not naturally fall into an existing bucket. 


4. Extensibility and Architecture 


In an idealized protocol model, extensible design would be self- 
contained, and it would be inherent that new extensions and new 
header fields would naturally have an architectural coherence with 
the original protocol. 


However, this idealized vision has not been attained in the world of 
Standards Track protocols. While interoperability implications can 
be addressed by capabilities negotiation rules, the effects of adding 
features that overlap, or that deal with a point solution and are not 
general, are much harder to control with rules. Therefore, the RAI 
Area calls for architectural guardianship and application of Occam’s 
Razor by the SIPCORE and DISPATCH Working Groups. 


In keeping with the IETF tradition of "running code and rough 
consensus", it is valid to allow for the development of SIP 
extensions that are either not ready for Standards Track, but might 
be understood for that role after some running code or are private or 
proprietary in nature because a characteristic motivating them is 


usage that is known not to fit the Internet architecture for SIP. In 
the past, header fields associated with those extensions were called 
"P-" header fields for "preliminary", "private", or "proprietary". 
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However, the "P-" header field process has not served the purpose for 
which it was designed -- namely, to restrict to closed environments 
the usage of mechanisms the IETF would not (yet) endorse for general 
usage. In fact, some "P-" header fields have enjoyed widespread 
implementation; because of the "P-" prefix, however, there seems to 
be no plausible migration path to designate these as general-usage 
header fields without trying to force implausible changes on large 
installed bases. 


Accordingly, this specification deprecates the previous [RFC3427] 
guidance on the creation of "P-" header fields. Existing "P-" header 
fields are to be handled by user agents and proxy servers as the "P-" 
header field specifications describe; the deprecation of the change 
process mechanism entails no change in protocol behavior. New 
proposals to document SIP header fields of an experimental or private 
nature, however, shall not use the "P-" prefix (unless existing 
deployments or standards use the prefix already, in which case they 
may be admitted as grandfathered cases at the discretion of the 
Designated Expert). 


Instead, the registration of SIP header fields in Informational RFCs, 
or in documents outside the IETF, is now permitted under the 
Designated Expert (per [RFC5226]) criteria. The future use of any 
header field name prefix ("P-" or "X-" or what have you) to designate 
SIP header fields of limited applicability is discouraged. Experts 
are advised to review documents for overlap with existing chartered 
work in the RAI Area, and are furthermore instructed to ensure the 
following two criteria are met: 


1. The proposed header field MUST be of a purely informational 
nature and MUST NOT significantly change the behavior of SIP 
entities that support it. Header fields that merely provide 
additional information pertinent to a request or a response are 
acceptable; these header fields are thus expected to have few, if 
any, implications for interoperability and backwards 
compatibility. Similarly, header fields that provide data 
consumed by applications at the ends of SIP’s rendezvous 
function, rather than changing the behavior of the rendezvous 
function, are likely to be providing information in this sense. 
If the header fields redefine or contradict normative behavior 
defined in Standards Track SIP specifications, that is what is 
meant by significantly different behavior. Ultimately, the 
significance of differences in behavior is a judgment call that 
must be made by the expert reviewer. 


2. The proposed header field MUST NOT undermine SIP security in any 
sense. The Internet-Draft proposing the new header field MUST 
address security issues in detail, as if it were a Standards 
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Track document. Note that, if the intended application scenario 
makes certain assumptions regarding security, the security 
considerations only need to meet the intended application 
scenario rather than the general Internet case. In any case, 
security issues need to be discussed for arbitrary usage 
scenarios (including the general Internet case). 


Note that the deprecation of the "P-" header field process does not 
alter processes for the registration of SIP methods, URI parameters, 
response codes, or option tags. 


4.1. SIP Event Packages 


SIP events [RFC3265] defines two different types of event packages: 


normal event packages and event template-packages. Event template- 
packages can only be created and registered by the publication of a 
Standards Track RFC (from an IETF Working Group). Note that the 


guidance in [RFC3265] states that the IANA registration policy for 
normal event packages is "First Come First Serve"; this document 
replaces that policy with the following: 


Individuals may wish to publish SIP Event packages that they believe 
fall outside the scope of any chartered work currently in RAI. 
Individual proposals for registration of a SIP event package MUST 
first be published as Internet-Drafts for review by the DISPATCH 
Working Group, or the working group, mailing list, or expert 
designated by the RAI Area Directors if the DISPATCH Working Group 
has closed. Proposals should include a strong motivational section, 
a thorough description of the proposed syntax and semantics, event 
package considerations, security considerations, and examples of 
usage. Authors should submit their proposals as individual Internet- 
Drafts and post an announcement to the working group mailing list to 
begin discussion. The DISPATCH Working Group will determine if a 
proposed package is 


a) an appropriate usage of SIP that should be spun into a new 
effort, 


b) applicable to SIP but not sufficiently interesting, general, or 
in-scope to adopt as a working group effort, 


c) contrary to similar work chartered in an existing effort, or 


d) recommended to be adopted as or merged with chartered work 
elsewhere in RAI. 
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"RFC Required" in conjunction with "Designated Expert" (both as 
defined in RFC 5226) is the procedure for registration of event 
packages developed outside the scope of an IETF working group, 
according to the following guidelines: 


1. A Designated Expert (as defined in RFC 5226) must review the 
proposal for applicability to SIP and conformance with these 
guidelines. The Designated Expert will send email to the IESG on 
this determination. The expert reviewer can cite one or more of 
the guidelines that have not been followed in his/her opinion. 


2. The proposed extension MUST NOT define an event template-package. 


3. The function of the proposed package MUST NOT overlap with 
current or planned chartered packages. 


4. The event package MUST NOT redefine or contradict the normative 
behavior of SIP events [RFC3265], SIP [RFC3261], or related 
Standards Track extensions. (See Section 4.) 


5. The proposed package MUST NOT undermine SIP security in any 
sense. The Internet-Draft proposing the new package MUST address 
security issues in detail as if it were a Standards Track 
document. Security issues need to be discussed for arbitrary 
usage scenarios (including the general Internet case). 


6. The proposed package MUST be clearly documented in an 
(Individual) Informational RFC and registered with IANA. The 
package MUST document all the package considerations required in 
Section 4 of SIP events [RFC3265]. 


7. If determined by the Designated Expert or the chairs or ADs of 
the DISPATCH WG, an applicability statement in the Informational 
RFC MUST clearly document the useful scope of the proposal, and 
explain its limitations and why it is not suitable for the 
general use of SIP in the Internet. 


5. Summary 


1. Documents that update or obsolete RFCs 3261 through 3265 must 
advance through the SIPCORE WG. 


2. Standard SIP extensions that do not update RFCs 3261 through 
3265, including event packages, may advance through chartered 
activity in any RAI Area WG or (with the agreement of the RAI 
ADs) any IETF working group that constitutes an appropriate 
venue. 


Peterson, et al. Best Current Practice [Page 10] 


RFC 5727 SIP Change March 2010 


3. Documents that specify Informational header fields pass through 
an Expert Review system. 


6. Security Considerations 


Complex, indeterminate, and hard-to-define protocol behavior, 
depending on the interaction of many optional extensions, is a fine 
breeding ground for security flaws. 


All Internet-Drafts that present new requirements for SIP must 
include a discussion of the security requirements and implications 
inherent in the proposal. All RFCs that modify or extend SIP must 
show that they have adequate security, must consider the security 
implications of feature interactions, and most of all must not worsen 
SIP’s existing security considerations. 


7. IANA Considerations 


RFC 3261 directs the Internet Assigned Numbers Authority (IANA) to 
establish a registry for SIP method names, a registry for SIP option 
tags, and a registry for SIP response codes, and to amend the 
practices used for the existing registry for SIP header fields. 
Reiterating the guidance of RFC 3261, method names, option tags, and 
SIP response codes require a Standards Action for inclusion in the 
IANA registry. Authors of specifications should also be aware that 
the SIP parameter registry is further elaborated in [RFC3968]. 


Previously in RFC 3427, all new SIP header field registrations 
required a Standards Action (per RFC 5226) with the exception of "P-" 
header fields; now, Informational registration of non-"P-" header 
fields is permitted if approved by a Designated Expert, as described 
in Section 4. 


Each RFC shall include an IANA Considerations section that directs 
IANA to create appropriate registrations. Registration shall be done 
at the time the IESG announces its approval of the draft containing 
the registration requests. 


Standard header fields and messages MUST NOT begin with the leading 
characters "P-". Existing "P-" header field registrations are 
considered grandfathered, but new registrations of Informational 
header fields should not begin with the leading characters "P-" 
(unless the "P-" would preserve compatibility with a pre-existing, 
unregistered usage of the header field, at the discretion the 
Designated Expert). Short forms of header fields MUST only be 
assigned to Standards Track header fields. 
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Similarly, [RFC3265] directs the IANA to establish a registry for SIP 
event packages and SIP event template-packages. For event template- 
packages, registrations must follow the [RFC5226] processes for 
Standards Action within an IETF working group. For normal event 
packages, as stated previously, registrations minimally require 


[RFC5226] "RFC Required" with "Designated Expert". In either case, 
the IESG announcement of RFC approval authorizes IANA to make the 
registration. 


7.1. Clarification of RFC 3969 


[RFC3969] stipulates that the (original) [RFC2434] rule of 
"Specification Required" applies to registrations of new SIP URI 
parameters; however, Section 3 of that same document mandates that a 
Standards Action is required to register new parameters with the 
IANA. This contradiction arose from a misunderstanding of the nature 
of the [RFC2434] categories; the intention was for the IANA 
Considerations to mandate that Standards Action is required. 


8. Overview of Changes to RFC 3427 
This section provides a high-level overview of the changes between 


this document and RFC 3427. It is not a substitute for the document 
as a whole -- the details are necessarily not represented. 


This document: 
1. Changes the description of the SIP and SIPPING WG functions to 


the SIPCORE and DISPATCH WG functions using the context of the 
RAI Area. 


2. Deprecates the process for "P-" header field registration, and 
changes the requirements for registration of SIP header fields of 
a purely informational nature. 


3. Updates IANA registry requirements, reflecting the publication of 
RFC 5226, clarifying the policies in RFC 3969, and clarifying 
that the original RFC 3237 updated the policies in RFC 3265. 
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